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I RSVP PROXY SERVICE FOR COMMUNICATION NETWORK 

BACKGROUND OF THE INVENTION 

Data communication switches are becoming more and more intelligent. Whereas legacy 
5 data communication switches provided indiscriminate first-in, first-out forwarding of packets, 
more recent data communication switches support differential packet forwarding based on flow 
characteristics under the Quality of Service (QoS) label. The trend toward QoS started first m 
c-U-switched ATM networks, but has migrated to packet-switched networks and. protocols, 
including bridging (Layer 2, or "L2"), routing (Layer 3. or "L3") and transport (Layer 4, or ••L4") 

10 P'°'°'°g'^^^^^^ ^,^^^^^3 ,^,,g,„g in packet switched networks. One standard 
element is a signaling protocol through which a QoS may be provisioned end-to-end for a flow 
This signaling protocol is called the Resource Reservation Protocol (RSVP). In conventional 
RSVP-signaled QoS provisioning, an RSVP-aware source host, called a "sender", desinng to 

15 initiate a flow with an RSVP-aware destination host, called a "receiver", transmits downstream 
an RSVP Path message specifying parameters for a proposed flow. Switches along the flowpath 
review the RSVP Path message and modify certain message fields as required to indicate 
limitations and conditions on their ability to deliver QoS services to the flow. The RSVT-aware 
destination host receives the RSVP Path message and uses the information therein to generate 

20 and transmit an RSVT Resv message back upstream requesting the provisiomng of a specific 
QoS for the flow at each switch along the flowpath. Each switch determines whether or not to 
accept the request based on whether the switch has sufficient available resources to provide the 
requested QoS and whether the flow is entitied to the requested QoS. If the reservation is 
accepted, the switches are configured to forward packets within the flow in accordance with the 

25 QoS. In this way, an RSVP-signaled QoS for the flow is provisioned end-to-end along .he 

^""^"^ile standard RSVT-signaled QoS, as outiined above, provides a means for end-to-end 
QoS provisioning withinanetwortitisonly known to beavailableforflowsbet^^^^^^ 
1 RSVP-aware. There is a need to extend the benefits of RSVP-signaled QoS to flows 
30 involving RSVP-unaware hosts. 

SUMMARY OF THE INVENTION ocvP angled 

The present invention provides RSVP host proxy services for extending RSVP-signaled 

QoS provisiomng to flows involving hosts that are not RSVP-aware ^ . „ 

InaccordancewithanRSVPsenderhostproxyservice,aswitchtiiroughwhichafirsthost 

. , r— fi^et Vinct T Innn receivme a data 



35 



In accordance wun an r^o owii^w.^w^.^.*^.., - _ 
accesses a network acts as an RSVP sender host proxy for the first host. Upon receiving a data 
flow from the first host, and determining that the RSVP sender host proxy 
service is enabled for the first host, the switch generates and transmits on a flowpath to a second 
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1 host an RSVP Path message. In accordance with RS VP, the RS VP Path message prompts the 
second host to generate and return on the flowpath an RSV? Res-/ message. 

In accordance with an RSVT receiver host proxy service, a switch through which a first 
host accesses a network acts as an RSVP receiver host proxy for the first host. Upon receiving 

5 an RSVP Path message generated and transmitted by a second host and determining that the 
RSVP receiver host proxy service is enabled for the first host, the switch generates and returns 

on a flowpath to the second host an RSVP Resv message. 

A switch serving as an RSVP host proxy for a host may condnue to act as an RSVP router 

for hosts. 

1 0 These and other aspects of the inventions may be better understood by reference to the 

following detailed description taken in conjunction with the accompanying drawings briefly 
described below. 

BRIEF DESCRIPTION OF THE DRAWINGS 
1 5 Figure 1 illustrates a network in which an RSVP sender host proxy service is operative; 

Figure 2 illustrates a switch supporting an RSVT sender host proxy function in the 

network according to Figure 1; 

Figure 3a illustrates the general format for a packet including an RSVP Path message; 
Figure 3b illustrates the general format for a packet including an RSVP Resv message; 
20 Figure 4 illustrates a network in which an RSVP receiver host proxy service is operative; 

Figure 5 illustrates a switch supporting an RSVP receiver host proxy function in the 

network according to Figure 4; 

Figure 6 is a flow diagram describing RSVP packet handling on a switch supporting an 
RSVP sender host proxy function in accordance with a preferred embodiment of the invennon; 

25 and . ^ . 

Figure 7 is a flow diagram describing RSVP packet handling on a switch supporting an 
RSVP receiver host proxy fiinction in accordance with a preferred embodiment of the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
30 In Figure 1 a network is shown in which a preferred RSV? sender host proxy service m 

accordance with the inventions operative. Tne network includes RSVP-unawaresourcehostllO 

having access to backbone network 1 30 via edge switch 1 40. Edge sw.ch 1 40 is coupled to edge 
switch 160 across backbone network 130 via one or more core switches (not shown) operative 
inbackbonenetwork 130. Edge switch 1 60 is coupled to RSVP-aware destination host 120.Edge 
35 switches 140, 160 are also coupled to policy servers 150, 170, respectively. 

Hosts 1 10 120 are preferably network end-stations, such as PCs, workstations or servers, 
having respective network interfeces for packetized communication with other hosts via edge 
switches 140, 160, respectively.Edge switches 140, 1 60 are preferably gateway devices, such as 
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hubs bridges or routers, having a plurality of respective network interfaces for forwarding 
packetizoi communications originated by hosts. Policy servers 150,170 retain quality or service 
(QoS) rules for application on edge switches 140, 160, respectively, based on rlow 
characteristics. Hosts 110, 120, edge switches 140, 160 and policy servers 150, 170__may be 
interconnected via cables or other transmission media, and may support various data 
communication protocols, such as Ethernet, Internet Protocol (IP) and Asynchronous Transfer 
Mode (ATM). Edge switches 140, 160 preferably support the router function of Resource 
Reservation Protocol (RSV?) set forth in Internet Engineering Task Force Request for Comment 
2205 entitled "Resource ReSerVation Protocol - Version 1 F-onctional Specification", September 
10 1997 (hereinafter RFC 2205). incorporated herein by reference. Destination host 1 20 preferably 
supports the RSVT receiver host function set forth in RFC 2205; however, source host 1 10 does 
not'support the RSVP sender host function set forth in RFC 2205. Instead, RSVP-signaied end- 
to-end QoS provisioning for data flows between source host 1 10 and destination host 120 is 
established through the expedient of an RSVP sender host proxy agent implemented on edge 

15 switch 140. , ^ J -.v. 

In its most basic feature, the RSVP sender host proxy service may be described with 
reference to Figure 1 . RSVP-unaware source host 1 10 initiates a data rlow by transmitting a data 
packet on the transmission medium interconnecting source host 1 1 0 with edge switch 1 40, the 
data packet having an address of source host 110 as a source address and an address ot 
20 destination host 120 as a destination address. Edge switch 140 receives the data packet 
determines that the data packet meets RSVT sender host proxy criteria, generates an RSVP Path 
message in accordance with an RSVT sender host function, modifies certain fields of the RSVP 
Path message if required in accordance with an RSVP router function, and transmits the RSVP - 
Path message on backbone network 130. The RSVP Path message traverses backbone network 
25 130 and edge switch 160 along a flowpath between source host 1 10 and destination host 120. 
whereat certain fields of the message may be modiiled at each "hop" in accordance with the 
RSVP router fiinction, and eventually arrives at RSVT-aware destination host 120. DestmaUon 
host 1 20, in response to the RSVP Path message, generates an RSVT Resv message requesung 
a QoS reservation in accordance with the RSVP receiver host fimction and transmits the RSVP 
30 Resv message on the transmission medium interconnecting destination host 1 20 and edge switch 
1 60 Edge switch 160 receives the RSVP Resv message and, in conjunction with policy server 
1 70 and in accordance with the RSVP router fiinctioa determines whether or not to accept the 
reservation The RSVP Resv message traverses backbone network 130 and edge switch 140 
along the flowoath, whereat it is determined at each "hop" in accordance with the RSVP router 
35 function whether to accept the reservation, with edge switch 140 making the determmanon m 
conjunction with policy server 150. 

Vanous elaborations of this basic RSVP sender host proxy service are possible as 
described hereinafter. Nevertheless, at a fundamental level, this basic proxy service, despite its 
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apparent simplicity, is believed to confer a significant advance over the prior an by expanding 
the reach of RSVP-signaled QoS provisioning to flows involving source hosts that are RSVP- 
unaware. 

Turning now to Figure 2 a preferred RSVP sender host proxy serWce will be described in 
even greater detail by reference to "on switch" processing on edge switch 140. Edge switch 140 
has networic interfaces 210. 220, 230 and management interfece 240 linked by data bus 250. 
Network interfaces 210, 220, 230 interconnect RSVP-unawaie source host 110, switches in 
backbone network 1 3 0 and policy server 1 50 over different interfaces. Management interfece 240 
supports various modules, including QoS mapper/classifier 241, QoS manager 242, policy 
manager 243. QoS driver 244, source learning 245 and RSVP 246. RSVP 246 includes RSVP 
router asent 247 and RSVP sender host proxy agent 248. Management interface 240 and network 
interfac^ 210, 220, 230 are linked by management bus 260 for transmitting and receiving 
management infonnation including QoS infonnation for various flows. 

Edge switch 140 supports RSVP processing as follows. RSVP message packets received 
on edge switch 140 are capnired off data bus 250 by management interface 140. RSVP message 
packets are forwarded to RSVP 246 for processing by RSVP routing agent 247 in accordance 
with the RSVP router function. RSVP router function processing of RSVP Path message packets 
includes modifying certain message fields as required to indicate limitations and conditions on 
the ability of switch 140 to deliver QoS services to the flow. RSVP router function processing 
20 of RSVP Resv message packets includes determining whether or not to accept requested QoS 
reservations based on whether switch 140 has sufficient available resources to provide the 
requested QoS and whether the flows in question are entitled to the requested QoS. The 
determinationofwhether or nottoacceptQoS reservations is made in conceit with QoS manager 

242 and policy manager 243. Rules defining applicable QoS limitations and conditions are 
25 "pulled down" to policy manager 243 from policy server 1 50 and applied in the detenninaUon. 
RSVP router fimction forwards RSVP Path message packets, including any modifications, to the 
"next hops" m the network and forwards RSVP Resv message packets, including any 
modifications, to the "previous hops" in the network. 

QoS manager 242 facilitates QoS establishment on switch 140 in accordance with 
30 accepted QoS reservations. For flows for which reservations have 'oeen accepted, QoS manager 
242 receives from policv manager 243 QoS policies, divides the QoS policies into flow identifier 
and QoS parts and for%vards the parts to the QoS mapped classifier 241 . Mapped classifier 241 
associates the flow identifiers with queues supporting the QoS and forwards the associauons to 
QoS driver 244, which establishes flow identifier/queue associations on network interfaces 2 1 0, 
35 270 230 via managemem bus 260 to implement the QoS policies on switch 140. 

In addition to the RSVP processing described above, edge switch 140 supports a novel 
RSVP sender host proxy fimction as follows. Data packets received on switch 140 and havmg 
unknown sourceaddressesarecapniredoffdatabus250by management interfacel40.Unknown 
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1 source address data packets are forwarded to source learning 245 for establishing associations 
on switch 140 between the source addresses and the network interfaces on which the source 
addresses arrived. Unknown source address data packets are also forwarded to QoS manager 242 
to detemine whether the RSVP sender host proxy function is enabled for the sources in question. 
5 Where enab led, unknown source address packets are forwarded to RSVP sender host proxy agent 
248 for processing in accordance with an RSVP sender host fimction. RSVP sender host fiinction 
processing includes generating RSVP Path message packets specifying parameters for the flows 
' in question and forwarding RSVP Path message packets for processing by RSVP routing agent 
247 in accordance with the RSVP router function as described earlier. 
10 Turning to Figure 3a. the general fonnat of an RSVP Path message packet is shown. Tne 

format and content of such a packet is well known and described in RPC 2205. Generally such 
a packet generally includes a Layer 2 headef 3 1 0 followed by a Uyer 3 header 320 and RSVP 
Path message 330. Layer 2 header 310 includes source and destination addressing information. 
Uyer 3 .header 320 is generally an IP header including source and destination addressing 
15 information and specifying protocol number- "46". RSVP Path message 330 includes an RSVP 
common header identifying the message as a Path message and an RSVP object includmg die 
contents of the Path message. The contents of the Path message include a Sender TSPEC 
describing the flow the sender expects to generate and an .^DSPEC. The Sender TSPEC traverses 
the flowpath from the RSVP sender to the RSVP receiver without modification, whereas the 
20 ADSPEC may be modified by switches along the flowpath to indicate the availability of QoS 
control services and parameters required for QoS control services to operate correctly. 

• Turning to Figure 3b. the general format of an RSVP Resv message packet is shown. The 
format and content of such a packet is well known and described in RFC 2205. GeneraUy such 
a packet generaUy includes a Uyer 2 header 340 followed by a Uyer 3 header 350 and RSVP 
25 Resv message 360. Layer 2 header 340 includes source and destination addressmg mfonnation. 
Layer 3 header 340 is generally an IP header including source and destination addressmg 
information and specifying protocol number "46". The RSVP Path message 350 includes an 
RSVP common header identifying the message as a Resv message and an RSVP object mcludmg 
the contents of the Resv message. The contents of the Resv message include a requested QoS 
30 control service, a Receiver TSPEC describing the flow for which resources should be reserved 
and if indicated by the requested QoS control service, a Receiver RSPEC descnbmg the level 
of service being requested. The contents together form a FLO WSPEC that traverses the flowpath 
from the RSVP receiver to die RSVP sender and may be modified by switches along the 

flowpath. , 
35 Turning now to Figure 4. a network is shown in which a preferred RSVP receiver host 

proxy service in accordance with the invention is operative. The network includes an RSVP- 
unaware destination host 410 having access to backbone network 430 via edge switch 440. Edge 
^^tch 440 is coup led to edge switch 460 via one or more core switches (not shown) m backbone 
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network 430. Edge switch 460 is coupled to RSVP-aware source host 420.. Edge switches 
440,460 are also coupled to policy servers 450,470, respectively. 

Hosts 410, 420 are preferably network end-stations, such as PCs, workstations or servers, 
having respective network interfaces for packetized communication with other hosts via edge 
switches 440, 460, respectively. Edge switches 440, 460 are preferably gateway devices, such as 
hubs, bridges or routers, having a plurality of respective network interfaces for forwarding 
packetized communications originated by hosts. Policy servers 450, 470 retain qualit>' of service 
(QoS) rules for application on switches 440, 460, respectively, based on flow characteristics. 
Hosts 410, 420, switches 440. 460 and policy servers 450, 470 may be interconnected via cables 
or other transmission media, and may support various protocols, such as Ethernet, IP and ATM. 
Edge switches 440, 460 preferably support the RSVP router function set fonh in RFC 2205. 
Source host 420 preferably supports the RSVP sender host function set forth in RFC 2205; 
however, destination host 4 1 0 does not support the RSVP receiver host function set forth in RFC 
2205. Consequently, end-to-end QoS provisioning for data flows between source host 420 and 
destination host 410 is established through the expedient of an RSVP receiver host proxy agent 
implemented on edge switch 440. 

In its most basic feature, the RSVP receiver host proxy service may be described with 
reference to Figure 4, RSVP-aware source host 420 generates in accordance with the RSVP 
sender host function an RSVP Path message having an address of RS VP-unaware destination 
host 410 as a destination address and transmits the RSVP Path message on the transmission 
medium interconnecting source host 420 with switch 460, Switch 460 receives the RSVP Path 
message, modifies certain fields of the message if required in accordance with the RSVP router 
function, and transmits the RSVP Path message on backbone network 430. Tne RSVP Path 
message traverses switches along the flowpath in backbone network 430 hop-by-hop whereat 
certain fields of the message may be modified in accordance with Lhe RSVP router fiincuon, and 
eventually arrives at switch 440. Sv/itch 440 modifies certain fields of the message in accordance 
with the RSVP router function, determines that the RSVP Path message packet meets RSVP 
receiver host proxy criteria, and generates in response an RSVP Resv message in accordance wth 
the RSVP receiver host function. Switch 440 determines, in conjunction with policy server 450 
and in accordance with the RSVP router f\mction, whe±er to accept the reservation itself prior 
to transmitting the RSVP Resv message back up the flowpath on backbone network 430. The 
RSVP Resv message traverses switches in backbone network 430 and switch 460, whereat it is 
determined hop-by-hop in accordance with the RSVP router function whedier to accept the 
reservation, with switch 460 making the determination in conjunction witii policy server 470. 

Various elaborations of this basic RSVP receiver host proxy service are possible as 
described hereinafter. Nevertheless, at a fundamental level, this basic proxy service, despite its 
apparent simplicity, is believed to confer a significant advance over die prior art by expanding 
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1 the reach of RS VP to allow end-to-end QoS provisioning for flows involving a destination host 
that is RSVP- 
unaware. 

Turning now to' Figure 5 a preferred RSV? receiver host proxy service will be described 
5 in greater detail by reference to "on switch" processing on edge switch 440. Switch 440 has 
network interfaces 5 1 0, 520, 530 and management interface 540 linked by data bus 550. Network 
interfaces 510, 520. 530 interconnect destination host 410, switches in backbone network 430 
and policy server 450 over different interfaces. Management interface 540 supports various 
modules, including QoS mapper/classifier 541, QoS manager 542, policy manager 543, QoS 
10 driver 544, source learning 545 and RSVP 546. RSVP 546 includes an RSV? router agent 547 
and an RSVP receiver host proxy agent 548. Management interface 540 and network interfaces 
510. 520, 530 are linked by management bus 560 for, transmining and receiving management 
information including QoS information for various flows. 

Switch 440 supports RSVP processing as follows. RSVP message packets received on 
1 5 switch 440 are captured off data bus 550 by management interface 540. RSVP message packets 
are forwarded to RSVP 546 for processing by RSVP routing agent 547 in accordance with the 
RSVT router function, subject to exceptions specified herein. In the case of RSVP Path message 
packets, RSVP router function processing includes modifying certain fields in the Path message 
as required to indicate liraiutions and conditions on the ability of switch 540 to deliver QoS 
20 services to the flow. In the case of RSVP Resv message packets, RSVP router fiinction 
processing includes determining whether or not to accept requested QoS reservations based on 
whether switch 440 has sufficient available resources to provide the requested QoS and whether 
the flows in question are entitled to the requested QoS. The determination of whether or not to 
accept QoS reservations is made in concert with QoS manager 542 and policy manager 543. 
25 Rules defining applicable QoS limitations and conditions are "pulled down" to policy manager 
543 from policy server 450 and applied in the determination. RSVP router function forwards 
RSVP Resv message packets, including any modifications, to the "previous hops" in the network. 
RSVP router function also forwards RSVP Path message packets, including any modifications, 
to the "next hops" in the network, except where the RSVP receiver host proxy fimction is enabled 
30 for the destinations in question. Where enabled, RSVP Path messages are not forwarded to the 

"next hops" in the network. 

In addition to the RSVP processing described above, switch 440 supports a novel RSVP 
receiver host pcoxy function as follows. RSVT Path message packets are forwarded to QoS 
manager 542 to determine whether the RSVP receiver host proxy function is enabled for the 
35 destinations in question. Where enabled, RSVP Path message packets are forwarded to RSVP 
receiver host proxy agent 548 for processing in accordance with an RSVP receiver host function. 
RSVP receiver host function includes.generating RSVP Resv message packets in response to the 



-7- 



wo 01/31829 PCT/USOO/41389 

[ RSVP Path message packets and forwarding the RSVP Resv message packets for processing by 
RSVP routing agent 547 in accordance with the RSVP router function as described earlier. 

In Figure 6, a flow diagram illustrates RSVP packet handling on a switch supporting an 
RSVP sender host proxy function in accordance with a preferred embodiment of the invention. 
5 A packet is received on the switch (610) and a determination is made whether the packet is an 
RSVP message packet (620). If the packet is an RSVP message packet, the packet is processed 
in accordance with the RSVP router fimction (650). If the packet is not an RSVP message packet, 
a determination is made whether the packet has a source address that is unknown to the switch, 
indicating a new flow for which a QoS has not yet been provisioned (630). If the packet has an 
1 0 unknown source address, a determination is made whether the RSVP sender host proxy service 
' is enabled for the source (640). If the RSVP sender proxy service is enabled for the source, an 
RSVP Path message packet is generated (650). The RSVP Path message is processed by the 
switch in accordance with the RSVP router fimction (660). If, however, the source address is 
known to the switch (per the detennination in Step 630), or if the RSVP sender host4)roxy 
1 5 service is not enabled for the source (per the determination in Step 640), RSVP processing of the 
received packet is terminated. 

In Figure 7, a flow diagram iUustrates RSVP packet handling on a switch supponing an 
RSVP receiver host proxy function in accordance with a preferred embodiment of the invention. 
A packet is received on the switch (710) and a determination is made whether the packet is an 
20 RSVP message packet (720). If the packet is an RSVP message packet, a determination is made 
whether the packet is an RSVP Path message packet (730). If the packet is not an RSVP Path 
message packet, RSVP processing of the received packet proceeds in accordance with the RSVP 
router function (740). If the packet is an RSVP Path message packet, however, a determination 
is made whether the RSVP receiver host proxy service is enabled for the destination (750). If the 
25 RSVP receiver host proxy service is not enabled for the destination, RSVP processing of the 
received packet proceeds in accordance with the RSVT router fimction (740). If the RSVP 
receiver host proxy service is enabled for the destination, however, RSVP processing of the 
received packet proceeds in accordance with the RSVP router fimction except the Path message 
is not forwarded by the switch to the "next hop" in the network (760), and an RSVP Resv 
30 message packet is generated (770). The RSVP Resv message is processed by the switch in 
accordance with the RSVP router function (780). 

It will be appreciated by those of ordinary skill in the art that the invention can be 
embodied in other specific forms without departing from the spirit or essential character hereof. 
"For instance, while the illustrated embodiments describe RSVP proxy-signaled end-to-end QoS 
35 provisioning for unicast flows between a source host and a single destination host, the invention 
may be applied to multicast flows between a source host and multiple destination hosts, wherem 
one or more switches act as RSVP host proxies for the source host and/or one or more of the 
destination hosts. The present description is therefore considered in all respects Ulustrative and 
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not restrictive. The scope of the invention is indicated by the appended claims, and all changes 
that come within the meaning and range of equivalents thereof 'are intended to be embraced 
therein. 
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We claim: 

1. A Resource Reservation Protocol (RSVP) proxy method for a communication 
network having a plurality of nodes, the method comprising: 

generating a data packet on a first node; 
transmining the data packet to a second node; 

determining on the second node in response to the data packet whether the second node 
is an RSVP proxy for the first node; 

generating an RSVP Path message in response to the determination; and 
transmitting the RSVT Path message to a third node. 

2. The method of claim 1, wherein the first node is a host and the second node is a 
switch. 

3. The method of claim 1 , wherein the determination is made in accordance_with a 
source address in the packet. 

4. A Resource Reservation Protocol (RSVP) proxy method for a communication 
network having a plurality of nodes, the method comprising: 

generating an RSVP Path message on a first node; 
transmitting the RSVP Path message to a second node; 

determining on the second node in response to the RSVP Path message whether the second 
node is an RSVP proxy for a third node; 

generating an RSVP Resv message in response to the determination; and 
transmitting the RSVP Resv message to the first node. 

5 . The method of claim 4, wherein the first node and the third node are hosts and the 
second node is a switch. 

6. The method of claim 4, wherein the detemination is made in accordance with a 
destination address in the packet. 

7 . An RSVP proxy method for a communication network having a plurality of hosts 
and a switch, the method comprising: 

transmining a data packet firom a first host to a switch; 

originating an RSVP Path mess^e on the switch in response to the data packet; 
transmitting the RSVP Path message from the switch to a second host; and 
transmitting an RSVP Resv message from the second host to the switch in response to the 
RSVP Path message. 
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8. The method according tp claim 7, wherein the first host is RSVP -unaware. 

9. Tne method according to ciaim 7, fanher comprising reserving resources along a 
flowpath between the second host and the switch in response to the RSVP Res-/ message. 

1 0. An RSVP proxy method for a communication network having a plurality of nodes, 
the method comprising: 

transmitting an RSVP Path message fh>m a first host to a switch; 

originating an RSVP Resv message on the switch in response to the RSVP Path message; 

transmitting the RSVP Resv message from the switch to the first host. 

11. The method according to ciaim 1 0, wherein the first host is RSVP-unaware. 

12. The method according to ciaim 1 1 , funher comprising reserving resources.along 
a flowpath between the first host and the switch in response to the RSVP Resv message. 

13. An RSVP proxy service for a communication network, comprising: 
a host for transmitting a data packet; 

an edge switch for receiving the data packet from the host; 

an RSVP host proxy agent on the edge switch for generating and transmitdng to a 
backbone network, in response to the data packet, an RSVP Path message. 

1 4. An RSVP proxy service for a commimication network, comprising: 
a host for transmitting an RSVP Path message; 

an edge svvitch for receiving the RSVP Path message from a backbone network; 
an RSVP host proxy agent on the edge switch for generating and transmitting to the 
backbone ner.vork, in response to the RSVP Path message, an RSVP Resv message. 

15. An RSVP proxy service for a communication network, comprising: 

a host connected to an edge switch, the edge switch managing the flow of data packets 
from the host to a backbone network; and 

wherein the edge switch receives a data packet from the host and in response generates and 
transmits an RSVP Path message on the backbone network. 

1 6. An RSVP proxy service for a commimication network, comprising: 

a host connected to an edge switch, the edge switch managing the flow of data packets 
from the host to a backbone network; and 
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wherein the edge switch receives an RSVP Path message destined for the host from the 
backbone network and in response generates and transmits an RSVP Resv message on the 
backbone network. 

1 7. An RSVP proxy service for a communication network, comprising: 

a first node connected to a second node, the second node providing an interface between 
the first node and a backbone network; and 

wherein the second node receives a data packet from the first node and in response 
generates and transmits an RSVP Path message on the backbone network. 

1 8. An RSVP proxy service for a communication network, comprising: 

a first node connected to a second node, the second node providing an interface between 
the first node and a backbone network; and 

wherein the second node receives an RSVP Path message destined for the first node from 
the backbone network and in response generates and transmits an RSVP Resv message on the 
backbone network. 

19. A signaling method for establishing an end-to-end Quality of Service (QoS) for a 
data flow in a communication network utilizing a signaling proxy, the method comprising: 

generating a data packet on a first node; 
transmitting the data packet to a second node; 

determining on the second node in response to the data packet whether ±e second node- 
is a QoS signaling proxy for the first node; 

generating a QoS message in response to the determination; and 
transmitting the QoS message to a third node. 

20. The method of claim 1 9, wherein die first node is a host and the second node is a 
switch. 

21. The method of claim 20, wherein the determination is made in accordance with a 
source address in the packet. 



22. The method of claim 20, wherein the QoS message specifies parameters for a data 

flow. 

23 . The method of claim 20, wherein the QoS message is modified in route to the third 
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24. A signaling method for establishing an end-to-end Quality of Service (QoS) for a 
data flow in a communication network utilizing a signaling proxy, the method comprising: 

generating a first QoS message on a first node; 
transmitting the first QoS message to a second node; 

determining on the second node in response to the QoS message whether the second node 
is a QoS signaling proxy for a third node; 

generating a second QoS message in response to the determination; and 
transmitting the second QoS message to the first node. 

25 . The method of claim 24, wherein theJirst node and the third node are hosts and the 
second node is a switch. 

26. Tne m.ethod of claim 24, wherein the determination is made in accordance with a 
destination address in the first QoS message. _ 

27. The method of claim 24. wherein the first QoS message specifies parameters for 
a data flow. 

28. The method of claim 24, wherein the first QoS message is modified in route to the 
second node, 

29. The method of claim 24, wherein the second QoS message requests establishment 
of a QoS for a data flow. 

30. The method of claim 24. wherein a QoS is established for a data flow at nodes 
along a flowpath between the second node and the first node in response to the second QoS 
message. 

31. A service for establishing end-to-end QoS in a communication network, 
comprising: 

a host connected to an edge switch, the edge switch managing the flow of data packets 
from the host to a backbone network; and 

wherein the edge switch receives a data packet from the host and in response generates and 
transmits a QoS message on the backbone network. 

32. The service according to claim 3 1 , wherein the QoS message specifies parameters 
for a data flow. 

33. A service for establishing end-to-end QoS in a communication network, comprising: 
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a host connected to an edge switch, the edge switch managing the flow of data packets 
from the host to a backbone network; and 

wherein the edge switch receives a first QoS message destined for the host from the 
backbone network and in response generates and transmits a second QoS message on die 
backbone network. 

34. The service according to claim 33, wherein the first QoS message specifies 
parameters for a data flow. 

35. The service according to claim 33, wherein the second QoS message requests 
establishment of a QoS for a data flow. 
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Figure 3A 
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Figure 7 
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